Skip to content

Conversation

@zimmermannJakob
Copy link

@zimmermannJakob zimmermannJakob commented Dec 7, 2025

Description

This PR solves issue #1694.

Checklist

Code Changes

  • Add test cases to all the changes you introduce
  • Run poetry all locally to ensure this change passes linter check and tests (Some error out on mac. I will investigate if they fail in ci)
  • Manually test the changes:
    • Verify the feature/bug fix works as expected in real-world scenarios
    • Test edge cases and error conditions (I thought about breaking changes and starting an empty changelog with prereleases.)
    • Ensure backward compatibility is maintained
    • Document any manual testing steps performed
      - [ ] Update the documentation for the changes (I do not think this applies. It works now as documented.)

### Documentation Changes

- [ ] Run poetry doc locally to ensure the documentation pages renders correctly
- [ ] Check and fix any broken links (internal or external) in the documentation

When running poetry doc, any broken internal documentation links will be reported in the console output like this:

INFO    -  Doc file 'config.md' contains a link 'commands/bump.md#-post_bump_hooks', but the doc 'commands/bump.md' does not contain an anchor '#-post_bump_hooks'.

Expected Behavior

See issue #1694.

Steps to Test This Pull Request

  1. build the changes on the branch. poetry build.
  2. Take the resulting .wheel file from dist/
  3. Install the file in a separate python environment:
  • python3 -m venv .venv && source .venv/bin/activate
  • verify env: which pip
  • pip install commitizen-4.10.0-py3-none-any.whl
  1. Go through the steps in the issue description and try reproducing the bug.

Additional Context

Known issue: When the changelog only contains pre-releases, the old behavior can still be observed. (Fixed)

@codecov
Copy link

codecov bot commented Dec 9, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (v4-11-0@2072f8e). Learn more about missing BASE report.

Additional details and impacted files
@@            Coverage Diff             @@
##             v4-11-0    #1700   +/-   ##
==========================================
  Coverage           ?   97.87%           
==========================================
  Files              ?       60           
  Lines              ?     2639           
  Branches           ?        0           
==========================================
  Hits               ?     2583           
  Misses             ?       56           
  Partials           ?        0           
Flag Coverage Δ
unittests 97.87% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@zimmermannJakob zimmermannJakob marked this pull request as ready for review December 13, 2025 14:29
Copy link
Member

@woile woile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice, thanks!

"incremental": True,
"dry_run": dry_run,
"during_version_bump": self.arguments["prerelease"]
is None, # We let the changelog implementation know that we want to replace prereleases while staying incremental AND the new tag does not exist already
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment is a bit unclear to me.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair. Was more of a note to self. I changed it to something more meaningful.

latest_version_index = index
line = line.strip().lower()

parsed = self.parse_version_from_title(line)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you rename the variable parsed to something more clear? Such as parsed_version. As well as the parsed in another function get_metadata_from_file.

Thanks!

Comment on lines 92 to 95
if parsed:
if not self.tag_rules.extract_version(
GitTag(parsed.tag, "", "")
).is_prerelease:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Combine these if statements with and

@zimmermannJakob
Copy link
Author

@woile @bearomorphism Thank you for your reviews!
@bearomorphism I applied your suggestions, but left the conversations open for you to verify. Where I disagreed with a suggestion, I stated why.

@bearomorphism
Copy link
Collaborator

The latest commit should not be chore. I'd suggest you to rebase the commits and adjust the commit messages, so the commit history will be cleaner after merging

@bearomorphism
Copy link
Collaborator

I believe there is a way to mock the datetime in your new tests

@bearomorphism
Copy link
Collaborator

bearomorphism commented Dec 16, 2025

I remember git commit timestamp can be specified

Thanks!🙏

@zimmermannJakob zimmermannJakob force-pushed the 1694-fix-changelog_merge_prerelease-not-working-on-cz-bump branch from 646cc6c to a16ff63 Compare December 20, 2025 14:58
@zimmermannJakob zimmermannJakob marked this pull request as draft December 20, 2025 15:00
@zimmermannJakob
Copy link
Author

@bearomorphism Thanks again for the review!

I believe there is a way to mock the datetime in your new tests

I used freezegun to set a fixed time.

I'd suggest you to rebase the commits and adjust the commit messages, so the commit history will be cleaner after merging

I tried that, but it shows a large diff now. Locally, if I do git diff upstream/master I see only my changes (changes.txt), so I am not sure why it shows the diff here on the PR. I used git reset --soft HEAD~7 to squash the commits. What did I do wrong? Any help is appreciated.

@bearomorphism bearomorphism changed the base branch from master to v4-11-0 December 20, 2025 17:38
@bearomorphism
Copy link
Collaborator

@zimmermannJakob could you try to rebase to v4-11-0? Thanks.

@zimmermannJakob zimmermannJakob force-pushed the 1694-fix-changelog_merge_prerelease-not-working-on-cz-bump branch from a16ff63 to 9cb370d Compare December 20, 2025 20:32
@zimmermannJakob zimmermannJakob force-pushed the 1694-fix-changelog_merge_prerelease-not-working-on-cz-bump branch from 9cb370d to e9f5ba9 Compare December 20, 2025 20:42
@zimmermannJakob zimmermannJakob marked this pull request as ready for review December 20, 2025 20:49
@zimmermannJakob
Copy link
Author

@bearomorphism Thank you, the diff looks good now!
Just out of curiosity, do you know what the issue was?
What is the etiquette surrounding open discussions? Should I close them if I deem them addressed, or do you close them as the creator of the discussion?

Anyway, the PR is good to go from my side.


- output glitch

## 0.1.0 (1970-01-01)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quick question, is this expected?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume you mean the empty version 0.1.0?

I would say yes. Reason is that an annotated tag is created on a version that has no eligible commits e.g. git commit -m "irrelevant commit" (see testcase). The Changelog command renders the release in that case as empty.
If this is not intended, I can modify the testcase to make it look 'more pretty' and open a new issue describing this bug. But I think it works as intended.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for detailed explanation. I don't think it's a blocker.

@woile wdyt

@bearomorphism
Copy link
Collaborator

What is the etiquette surrounding open discussions? Should I close them if I deem them addressed, or do you close them as the creator of the discussion?

I would say it depends. I think PR creators can close the discussion themselves once they think the issue is resolved, but I also have seen in some cultures it's the reviewers closing the discussion.

Another option is to simply reply "fixed", but there are also people think it looks verbose if under every discussion there is a "fixed" comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants